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IMAP4 Non-synchronizing Literals 


Abstract 


The Internet Message Access Protocol (RFC 3501) contains the 
"literal" syntactic construct for communicating strings. When 
sending a literal from client to server, IMAP requires the client to 
wait for the server to send a command continuation request between 
sending the octet count and the string data. This document specifies 
an alternate form of literal that does not require this network round 
trip. 


This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. 
LITERAL+ allows the alternate form of literals in all IMAP commands. 
LITERAL- is the same as LITERAL+, but it disallows the alternate form 
of literals unless they are 4096 bytes or less. 
This document obsoletes RFC 2088. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7888. 
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include Simplified BSD License text as described in Section 4.e of 
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described in the Simplified BSD License. 
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10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
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Without obtaining an adequate license from the person(s) controlling 
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outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
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Les 


Introduction 


The Internet Message Access Protocol [RFC3501] contains the "literal" 
syntactic construct for communicating strings. When sending a 
literal from client to server, IMAP requires the client to wait for 
the server to send a command continuation request between sending the 
octet count and the string data. This document specifies an 
alternate form of literal that does not require this network round 
trip. 


This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. 
LITERAL+ allows the alternate form of literals (called "non- 
synchronized literals" below) in all IMAP commands. LITERAL- is the 
same as LITERAL+, but it disallows the alternate form of literals 
unless they are 4096 bytes or less. 


Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


In examples, "C:" and "S:" indicate lines sent by the client and 
server, respectively. If a single "C:" or "S:" label applies to 
multiple lines, then the line breaks between those lines are for 
editorial clarity only and are not part of the actual protocol 
exchange. 


Specification 


The non-synchronizing literal is added as an alternate form of 
literal, and it may appear in communication from client to server 
instead of the IMAP [RFC3501] form of literal. The IMAP form of 
literal, used in communication from client to server, is referred to 
as a synchronizing literal. The non-synchronizing literal form MUST 
NOT be sent from server to client. 


Non-synchronizing literals may be used with any IMAP server 
implementation that returns "LITERAL+" or "LITERAL-" as one of the 
supported capabilities to the CAPABILITY command. If the server does 
not advertise either of the above capabilities, the client can only 
use synchronizing literals. The difference between LITERAL+ and 
LITERAL- extensions is explained in Section 5. 


The non-synchronizing literal is distinguished from the original 
synchronizing literal by having a plus (’+’) between the octet count 
and the closing brace (’}’). The server does not generate a command 
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continuation request in response to a non-synchronizing literal, and 
clients are not required to wait before sending the octets of a non- 
synchronizing literal. 


The protocol receiver of an IMAP server MUST check the end of every 
received line (a sequence of octets that ends with a CRLF) for an 
open brace (’{’) followed by an octet count, a plus (’+’), anda 
close brace (’}’) immediately preceding the CRLF. This sequence (if 
found by the receiver) is the octet count of a non-synchronizing 
literal, and the server MUST treat the specified number of following 
octets and the following line (as defined in [RFC3501]) as part of 
the same command. 


It’s important to note that the literal is not delimited by CRLF. It 
ends after the number of bytes specified by the octet count, and the 


current command continues from there. There might be a CRLF 
immediately after; it ends the command. Or, there might be more 
octets, specifying other command parameters, before the CRLF. Ifa 


SP (space) character is needed between parameters, it’s important 
that the SP appear after the literal, in its appropriate place. 


A server MAY still process commands and reject errors on a line-by- 
line basis, as long as it checks for non-synchronizing literals at 
the end of each line. 


Example: 

C: A001 LOGIN {11+} 

C: FRED FOOBAR {7+} 

C: fat man 

S: A001 OK LOGIN completed 


This is semantically equivalent to this version that uses quoted 
strings instead of literals: 


C: A001 LOGIN "FRED FOOBAR" "fat man" 
S: A001 OK LOGIN completed 


Note that the space after FOOBAR in the first version corresponds 
to the space between the two quoted strings in the second. 
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4. Considerations on When to Use and Not to Use Synchronizing Literals 


Understanding of this section is important for both client and server 
developers of this IMAP extension. 


While non-synchronizing literals have clear advantages for clients, 
such as simplicity of use, they might be more difficult to handle on 
the server side. When a client uses a non-synchronizing literal that 
is too big for the server to accept, a server implementation that is 
compliant with LITERAL+ has to make a choice between a couple non- 
optimal choices: 


1. Read the number of bytes specified in the non-synchronizing 
literal and reject the command that included the literal anyway. 
(The server is allowed to send the tagged BAD/NO response before 
reading the whole non-synchronizing literal.) This is quite 
wasteful of bandwidth if the literal is large. 


2. Send an untagged BYE response explaining the reason for rejecting 
the literal (possibly accompanied by an ALERT response code in 
another response) and close the connection. This will force the 
client to reconnect or report the error to the user. In the 
latter case, the error is unlikely to be understandable to the 
user. Additionally, some naive clients are known to blindly 
reconnect in this case and repeat the operation that caused the 
problem, introducing an infinite loop. 


The problem described above is most common when using the APPEND 
command, because most commands don’t need to send lots of data from 
the client to the server. Some server implementations impose limits 
on literals (both synchronizing and non-synchronizing) accepted from 
clients in order to defend against denial-of-service attacks. 
Implementations can generally impose much lower limits on literal 
sizes for all commands other than APPEND. In order to address 
literal size issue in APPEND, this document introduces a new 
extension LITERAL-, described in Section 5. 


The situation can also be improved by implementing support for the 
APPENDLIMIT extension [RFC7889], which allows a server to advertise 
its APPEND limit, so that well-behaved clients can check it and avoid 
uploading big messages in the first place. 


5. LITERAL- Capability 
The LITERAL- extension is almost identical to LITERAL+, with one 
exception: when LITERAL- is advertised, non-synchronizing literals 


used in any command MUST NOT be larger than 4096 bytes. Any literal 
larger than 4096 bytes MUST be sent as a synchronizing literal as 
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specified in RFC 3501. A server that is compliant with LITERAL- and 
encounters a non-synchronizing literal larger than 4096 bytes 
proceeds as described in Section 4. If responding to an APPEND 
command, the tagged BAD response MUST contain the TOOBIG response 
code [RFC4469]. If responding with an untagged BYE response, it 
SHOULD include the TOOBIG response code. Note that the form of the 
non-synchronizing literal does not change: it still uses the "+" in 
the literal itself, even if the applicable extension is LITERAL-. 


Because LITERAL- is a more restricted version of LITERAL+, IMAP 
servers MUST NOT advertise both of these capabilities at the same 
time. (A server implementation can choose to have a configuration 
option to indicate which one to advertise.) 


6. Interaction with BINARY Extension 
[RFC4466] updated the non-terminal "literal8" defined in [RFC3516] to 
allow for non-synchronizing literals if both BINARY [RFC3516] and 
LITERAL+ extensions are supported by the server. 
This document also allows use of this extended "literal8" syntax when 
both BINARY [RFC3516] and LITERAL- extensions are supported by the 
server. 

7. (Interaction with MULTIAPPEND Extension 
[RFC3502] describes MULTIAPPEND extension and how it can be used with 
LITERAL+. The LITERAL- extension can be used with the MULTIAPPEND 
extension in the same way. 


8. Formal Syntax 


The following syntax specification uses the Augmented Backus-Naur 
Form (ABNF) notation as specified in [ABNF]. 


Non-terminals referenced but not defined below are as defined by 


[RFC3501]. 
literal = "{" number ["+"] "}" CRLF *CHAR8 
; Number represents the number of CHAR8 octets 
CHAR8 = <defined in RFC 3501> 


literal8 = <defined in RFC 4466> 
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Dis 


10. 


Lig 


ti; 


Security Considerations 


Use of non-synchronizing literals can consume extra resources (e.g. 
memory) on IMAP servers and can be used for denial-of-service 
attacks. The LITERAL- extension partially improved this situation. 


This document doesn’t raise any security concerns beyond those raised 
by [RFC3501]. 


IANA Considerations 
IMAP4 capabilities are registered by publishing a Standards Track or 


IESG-approved Experimental RFC. The registry is currently located at 
<http://www.iana.org/assignments/imap-capabilities>. 


IANA has updated the above registry so that the reference for 
"LITERAL+" points to this document. 


IANA has added the "LITERAL-" capability to the above registry, with 
this document as the reference. 
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Appendix A. Changes since RFC 2088 
Added IANA registration. 


Updated references. Also updated considerations about interactions 
of IMAP extensions. 


Added implementation considerations based on the IMAP mailing list 
discussions. 


Added description of a new capability: LITERAL-. 
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